It is commonly known that administrative tasks include software testing various entities (e.g., software components, network protocols, etc.) using various script executing platforms (e.g., Windows PowerShell® platform) that use test execution scripts (e.g., PowerShell script) and are powered by extensible automated engines, such as PowerShell® invocation engine (e.g., System.Management.Automation.dll), and software frameworks (e.g., .NET framework). However, complications occur when testing is to be performed based on various (software and/or hardware) configuration settings, and the testing process becomes even more convoluted, and even unmanageable, when one or more configuration settings are to be modified. This is because today's testing solutions require testing team members (e.g., software developers) to build a test execution platform or infrastructure with multiple rules/regulations and configuration setting variants to accommodate each test and its corresponding hardware and software configuration settings, separately and independently, which, at best, requires constant supervision and rerunning of failed tests and, at worst, becomes overly complex and unmanageable. Further, to retrieve any relevant test result information, a testing system has to be stopped and a large number of rules and relationships have to be changed and saved which makes the retrieval process overly complex, convoluted, and unmanageable.